合約帳戶的模組化系統，能夠讓用戶自行安裝或移除合約帳戶的某項功能，例如安裝一個模組，讓合約帳戶可以透過 email 來恢復使用權限，或安裝另個模組，能夠允許自動化執行特定交易。模組化系統將有助於合約帳戶整個生態系的發展，對用戶和開發者來說都具有高度的自由性。

Alchemy 提出 ERC-6900 Modular Smart Contract Accounts and Plugins，之後有另一批人提出 ERC-7579 Minimal Modular Smart Accounts。此外我也發現，Safe{Wallet} 本身沒有遵循 ERC-4337，有自己的模組化系統，可以安裝 ERC-4337 的模組，也可以安裝 ERC-7579 的模組，目前看下來，合約帳戶與模組化的生態系仍屬於戰國時期的感覺。

• BundleBear 可以觀察目前 AA 生態系的市占率。

今天要來筆記的是 ERC-7579，主要由 Rhinestone 提供多項已開發的模組，ZeroDev 和 Biconomy 的合約帳戶都有支援。

ERC-7579 定義四種模組種類：

• Validation (type id: 1): 用於驗證階段的模組，例如使用 ECDSA 簽章或 WebAuthn。
• Execution (type id: 2): 用於執行階段的模組，例如自動化交易。
• Fallback (type id: 3): 針對合約帳戶 fallback 的模組。
• Hooks (type id: 4): 在執行交易前或執行交易後呼叫特定函式的模組。

一個模組合約的介面：

interface IModule {
    function onInstall(bytes calldata data) external;
    function onUninstall(bytes calldata data) external;
    function isModuleType(uint256 moduleTypeId) external view returns(bool);
}

合約帳戶為了要能夠支援模組的安裝與移除等等，也有規定一些介面：

interface IExecution {
    function execute(bytes32 mode, bytes calldata executionCalldata) external;
    function executeFromExecutor(bytes32 mode, bytes calldata executionCalldata) external returns (bytes[] memory returnData);
}

interface IAccountConfig {
    function accountId() external view returns (string memory accountImplementationId);
    function supportsExecutionMode(bytes32 encodedMode) external view returns (bool);
    function supportsModule(uint256 moduleTypeId) external view returns (bool);
}

interface IModuleConfig {
    event ModuleInstalled(uint256 moduleTypeId, address module);
    event ModuleUninstalled(uint256 moduleTypeId, address module);

    function installModule(uint256 moduleTypeId, address module, bytes calldata initData) external;
    function uninstallModule(uint256 moduleTypeId, address module, bytes calldata deInitData) external;
    function isModuleInstalled(uint256 moduleTypeId, address module, bytes calldata additionalContext) external view returns (bool);
}

驗證階段的模組化

好奇看了一下 ZeroDev 的 Kernel 如何實踐模組化，在合約帳戶 Kernel.sol 和 ECDSA 驗證模組 ECDSAValidator.sol 都可以看到 validateUserOp 的函式。

Kernel 安裝 ECDSAValidator 模組後，會得到一個 vId，在驗證階段，EntryPoint 會呼叫合約帳戶的 validateUserOp，這時呼叫的是 Kernel.sol 的 validateUserOp，用戶要在 userOp.nonce藏一個 vId 的值，Kernel 的 validateUserOp 會根據 vId 再去呼叫 ECDSAValidator 的 validateUserOp。

Biconomy 則是把驗證模組的地址藏在 userOp.signature，看起來是比 Kernel 簡單好懂一點：

--

總之，模組化的實踐方式會因各個合約錢包而異，我發現 Biconomy 雖然實踐 ERC-7579 安裝模組的功能，但安裝函式叫 enableModule 而不是 installModule。不同函式名稱可能會導致模組安裝平台需要依不同合約自訂的介面去實作，就少了統一介面帶來的便利性。

許多在 EOA 做不到的應用，能夠以模組化的形式擴充合約錢包的功能，想必在未來能發展出更多創新應用。模組化的好處，能夠最小化合約帳戶的核心，並且讓使用者能夠自由選擇錢包所需要的功能，開發者也能針對特定功能做最必要的開發。

最後，推薦 rehash podcast 一集關於 AA 的訪談: Improving UX With Account Abstraction w/Nichanan Kesonpat (1kx) | MINIHASH 004